Video

UML-klassennotatie

1. Een klasse gebruik je op de 'dingen' (objecten) die in de applicatie voorkomen te beschrijven. In de u-trip (moe maar tevreden) applicatie hebben we dingen zoals een uitstap, een bezienswaardigheid, een begeleider, een toerist, enz.

   

   1. De volgende regels moeten in acht worden genomen bij het voorstellen van een klasse:

      1. de naam van een klas moet altijd beginnen met een hoofdletter;

      2. een klassenaam moet altijd in het midden van het eerste compartiment staan;

      3. een klassenaam moet altijd vetgedrukt worden geschreven;

      4. een abstracte klassenaam moet cursief worden geschreven;

   2. Het standaard klassendiagram is opgebouwd uit drie delen:

      1. Bovendeel: bevat de naam van de klas. Deze sectie is altijd vereist.

      2. Middelste gedeelte: bevat de attributen van de klasse. Gebruik dit gedeelte om de eigenschappen van de klas te beschrijven.

      3. Onderste gedeelte: bevat klassebewerkingen (methoden). Weergegeven in lijstformaat, neemt elke bewerking een eigen regel in beslag. De bewerkingen beschrijven hoe een klasse omgaat met gegevens.

2. Een ding (object) is een exemplaar van een bepaalde klasse. In het Engels spreekt men van instance en in slecht Nederlands van instantie. De uitstap naar de Dolmens en de Menhirs in de Sarthe is een ding, een exemplaar, een object of een instantie van de klasse uitstap. Andere dingen van de uitstap klasse kunnen een uitstap naar Parijs of Amsterdam zijn, een uitstap naar de Zoo van Antwerpen enz. Een ding of een exemplaar van de klasse begeleider kan Tom Waes of een leerkracht van een school. En een toerist, dat kan iedereen zijn, Jan, Mohammed, Sarah, ...
3. Een attribuut beschrijven de eigenschappen die de objecten van een klasse hebben.
   1. Een attribuuttype signeert het attribuut, het geeft aan welk soort gegeven een attribuut is:

      Type	Waarden die een attribuut met dit type kan hebben
      int
      float
      string
      time
      date
      datetime
      proces	(bedrijfs)proces/procedure
      bedrag in € / £ / $	geldbedrag en munteenheid
      boolean	waar of vals, ja of nee

   2. verplichte (Engels: required) attributen: voor elk object van de klasse moeten deze attributen een waarde hebben.
   3. optionele (Engels: optional) attributen: het is niet nodig dat voor elk object van de klasse deze attributen een waarde te hebben. Als een attribuut optioneel is wordt dit aangegeven door [0..1] achter het attribuuttype te plaatsen. Attributen waar dit niet achter staat, zijn verplichte attributen.
   4. In een opsommingslijst (Engels: enumeration list) staan alle mogelijke waarden van een attribuut. Een opsommingslijst kan gebruikt worden als type van een attribuut.

4. methode (operations/methods)

   1. methoden worden weergegeven in de derde partitie. Het zijn diensten die de klasse biedt;

   2. het retourtype van een methode wordt weergegeven na de dubbele punt aan het einde van de methodehandtekening;

   3. het retourtype van methodeparameters wordt weergegeven na de dubbele punt na de parameternaam;

   4. richting van de parameters

      Elke parameter in een operatie (methode) kan worden aangeduid als in, out of inout, wat de richting aangeeft met betrekking tot de caller. Deze directionaliteit wordt weergegeven vóór de parameternaam.

5. Klasse zichtbaarheid

   De +, - en # symbolen die voor een attribuut en methodenaam in een klasse staan, geven de scope van het attribuut en de methode aan:

   1. + geeft openbare (public) attributen of operaties/methoden aan;

   2. - geeft privé (private) attributen of operaties aan;

   3. # geeft beveiligde (protected) attributen of methoden aan

Klassendiagram in de levenscyclus van softwareontwikkeling

Klassendiagrammen kunnen worden gebruikt in verschillende fasen van softwareontwikkeling. Een diagram kan vanuit verschillende perspectieven worden geïnterpreteerd. Het perspectief is afhankelijk van de hoeveelheid details en de soorten relaties die je wilt presenteren. De klassenaam is de enige verplichte informatie.

Als voorbeeld gebruiken we de gegevens van u-trip / mmt applicatie.

1. conceptueel perspectief: vertegenwoordigt de concepten in het domein:

   

2. specificatieperspectief beschrijft software-abstracties of componenten met specificaties en interfaces (Abstract Data Type of ADT's) . Het geeft echter geen enkele toezegging tot specifieke implementatie.

   

3. implementatie perspectief: dit type klassendiagrammen wordt gebruikt voor implementaties in een specifieke taal of applicatie. Implementatieperspectief wordt gebruikt door IT voor software-implementatie:

   

Verwantschappen tussen klassen

1. Een associatie drukt een verband (verwantschap) uit tussen klassen.
   Associaties zijn verwantschappen tussen klassen in een UML-klassendiagram. Ze worden weergegeven door een ononderbroken lijn die tussen de klassen getekend wordt. De naam van associaties worden meestal vormd door een werkwoord of werkwoordsuitdrukking die het echte probleemdomein weerspiegelt:
   Een uitstap bestaat uit een aantal exemplaren van bezienswaardigheid. En een begeleider begeleidt een uitstap. En een deelnemer neemt deel aan een uitstap.
   1. eenvoudige associatie

      

   2. multipliciteit/cardinaliteit (Engels: cardinality/multiplicity) drukt de associatie cijfers uit:
      1. in twee richtingen:
         1. een uitstap bestaat uit minstens 1 of meer bezienswaardigheden (1..*)
         2. een bezienswaardigheid kan in geen enkele uitstap of in meerdere uitstappen voorkomen (* is afkorting van 0..*)
      2. de mogelijke waarden:

         multipliciteit	aantal objecten dat geassocieerd kan zijn:
         1	één enkel (afkorting van 1..1)
         0..1	geen of 1
         *	geen of meer (afkorting van 0..*
         1..*	minstens 1 of meer

         Je kan ook andere waarden gebruiken. Multipliciteit 2..4 geeft aan dat er minstens twee en maximaal vier objecten geassocieerd zijn.

         

      3. Het probleem van de kip en het ei
         In het voorbeeld hierboven kan je slechts een Tour toevoegen als je ook een bezienswaardigheid eraan koppelt. Dat maakt het lastig voor de makers van de Tour. Want dan moeten eerst de bezienswaardigheden worden ingevoerd. Als je de gebruiker wilt toelaten om de gegevens van de Tour al in te vullen vooraleer de bezienswaardigheden te maken moet je de cardinaliteit wijzigen:

         

      4. Benoemde associatie

         

2. Aggregatie en compositie (samenstelling) zijn deelverzamelingen van associatie. Dat betekent dat het specifieke gevallen van associatie zijn. In zowel aggregatie als compositie bezit object van de ene klasse een object van een andere klasse. Maar er is een subtiel verschil:
   1. Aggregatie impliceert een relatie waarin het kind onafhankelijk van de ouder kan bestaan. Voorbeeld: Tour (ouder) en Curioristy (kind). Verwijder de Tour en de Curiosities bestaan nog steeds:

      

   2. Compositie impliceert een relatie waarin het kind niet onafhankelijk van de ouder kan bestaan. Voorbeeld: Cusiosity (ouder) en Comment (kind). Comments bestaan niet los van een Curiosity:

      

3. generalisatie en specialisatie:
   1. Generalisatie is een mechanisme voor het combineren van vergelijkbare klassen van objecten tot een enkele, meer algemene klasse. Generalisatie identificeert overeenkomsten tussen een reeks entiteiten. Dat kunnen zowel gemeenschappelijke attributen of methoden zijn. Met andere woorden, een superklasse heeft de meest algemene attributen, bewerkingen en relaties die met subklassen kunnen worden gedeeld. Een subklasse kan meer gespecialiseerde attributen en bewerkingen hebben. Een superklase:
      1. vertegenwoordigt een "is-a" -relatie;
      2. de een abstracte klassenaam ervan wordt cursief weergegeven;

      Generalisatie is de term die we gebruiken om abstractie van gemeenschappelijke eigenschappen in een basisklasse in UML aan te duiden. De generalisatie-associatie van het UML-diagram wordt ook wel Inheritance genoemd. Wanneer we generalisatie in een programmeertaal implementeren, wordt dit vaak Inheritance genoemd. Generalisatie en overerving zijn hetzelfde. De terminologie verschilt gewoon afhankelijk van de context waarin deze wordt gebruikt.
      Bijvoorbeeld de begeleider en de deelnemer (toerist) delen gemeenschappelijke eigenschappen zoals voornaam, familienaam, enz. Die gemeenschappelijke attributen en methoden stoppen we in een abstracte klasse Person.

   2. Specialisatie is het omgekeerde proces van generalisatie: het creëren van nieuwe subklassen uit een bestaande klasse.
      De abstracte klasse Person kunnen we specialiseren in de klasse begeleider en deelnemer.

   De onderstaande afbeelding toont een voorbeeld van een hiërarchie van generalisatie-specialisatie . Deelnemer en Begeleider zijn afgeleid van Person. De relatie wordt weergegeven als een ononderbroken lijn met een holle pijlpunt die van het onderliggende element naar het bovenliggende element wijst:

   

Opdracht

1. Op basis van de functionele analyse en het ERD VOS maak je een klassendiagram voor de VOS applicatie.
   1. Voeg op basis van de functionele analyse methoden aan de klassen toe.
      Bijvoorbeeld:
      1. zoek de school die zich het dichtst bij de plaats bevindt waar de gebruiker van de app staat;
      2. tel het aantal stappen in een procedure;
      3. bereken het aantal keer dat een gebruiker een actie heeft ondernomen (bellen of sms'en)
   2. Bepaal de associaties tussen de klassen. Hou rekening met:
      1. aggregatie en compositie
      2. generalisatie en specialisatie
2. Sla je werk op in het Worddocument dat je voor de vorige opdrachten hebt gebruikt en stuur het door via Digitap.

Bronnen

1. UML Class Diagram Tutorial

2. UML Association vs Aggregation vs Composition

Paragraaf